People who are deaf or hearing impaired may make use of communication terminals specifically constructed and designed to enable such persons to converse over the telephone lines. Such devices are referred to as telecommunication devices for the deaf or TDDs (or TTYs). Typically, the TDDs include a keyboard and a display connected to the telephone through a modem (modulator/demodulator). The modem is built into the TDD and either directly connected to a telephone line or coupled by an acoustic coupler to a normal telephone handset. TDDs are normally capable of transmitting information over telephone lines by means of coded tones to other TDDs connected at opposite ends of the telephone line through another modem.
The code and protocol which is in widespread conventional use for TDD communication is an idiosyncratic one. The code set, known as Baudot, and the communication protocol, referred to here as Baudot/Weitbrecht, evolved historically at a time when many telecommunication devices for the deaf were based on mechanical or electromechanical devices rather than electronic devices. Accordingly, the protocol was constructed for a set of constraints which no longer are relevant to present day devices. As it happens, those constraints work to create a code protocol and a telecommunication network of users and devices operating under that protocol, which is now perceived to have certain deficiencies.
One deficiency with the Baudot/Weitbrecht protocol is simply speed. Conventional Baudot/Weitbrecht communication is conducted at 45.5 Baud (or in some countries 50 Baud). The normal Baudot character set consists of five bit characters. Under conventional Baudot/Weitbrecht communication, there is a start bit (one space or zero bit), a five bit character, and at least one and 1/2 stop bits (a mark or a one bit). The result is that operating under the protocol, it is possible to transmit only six characters per second. As it happens, many adept typists among TDD communicators are ready able to type at rates significantly in excess of six characters per second. While modern microprocessor-based TDDs are capable of buffering such adept typists, the result is that the transfer of communications from one TDD terminal to another can, at times, be significantly delayed behind a fast typist. This has been a source of frustrations to users in the TDD community for some time.
Another deficiency with conventional TDDs operating under Baudot/Weitbrecht protocols has to do with the fact that communication is defined to be simplex, meaning that only one terminal is capable of communicating at one time. Since both transmitting and receiving stations use the same frequencies for designating marks and spaces on the telephone (14,000 Hertz for a mark and 18,000 Hertz for a space) both stations cannot send data at the same time without interference. There is no provision for avoiding such interference in the conventional Baudot/Weitbrecht protocol. Instead, prior machines are designed to give priority to data transmission. The devices will transmit a character if the key is pressed, and while the device is sending, no attempt is made to receive data.
As a result of this simplex operation of present Baudot machines, in order to approximate the given take of normal conversation, TDD users generally have to indicate to the other user when that user that has the "floor" is ending that particular communication. For example, it is quite common convention in the United States to type the letters "GA" as an abbreviation for "go ahead" at the end of a text string to indicate to the other user that it is his or her turn to type. A user who wishes to interrupt a transmission is not successful in communicating to the other device, which is not monitoring for messages during its transmission, and typically garbles the data being received at that time.
Yet another deficiency with the Baudot/Weitbrecht protocol is in the limited number in bits employed to represent characters. With 26 letters and 10 numerals, generally, full representation of an alphanumeric set requires six bits or 64 possible code words, enough to cover the letters (in either upper or lower case, but not both) the numbers and 28 punctuation symbols and control signals. The Baudot code only provides 32 code words primarily used for upper case alphabetic characters which may be extended by a mode change character to provide numeric symbols and some punctuation symbols. Failure of one TDD to properly interpret this mode change character may result in a garbling where subsequent characters are misinterpreted as numbers rather than letters or vice versa.
This shortage of possible code words also requires that specialty commands communicating between one TDD and another must be constructed of a series of character strings that may be inherently recognized as not being text to be read by the user. There is presently no established protocol to designate such nontext data.
These deficiencies while primarily an inconvenience to the user, also prevent useful increased functionality of TDD devices. One such improved function would be the automatic and rapid transmission of large blocks of text data that have been preprogrammed by the user, the transmission being invisible to the user. Such transmission might be useful for communicating user identification information to an emergency service. In the present Baudot/Weitbrecht protocol, such large blocks of data would take considerable time to transmit and because of the lack of duplex capability carry the risk of being interrupted by the TDD operator who remains unconscious of the automatic transmission. Also, because of the slow rate of Baudot communication, large blocks take comparably large amounts of time to transmit and therefore cannot be transmitted invisibly to the user, who at a minimum must wait for the transmission for a period of time that may approach the amount of time it would take to type material himself or herself.
The low speed of Baudot and the lack of extra codes which can be designated with particular functions seriously curtails the implementation of automatic machine-to-machine communication over the phone lines. The required multiple strings of characters necessary to differentiate such nontext messages for text messages are unwieldy, interrupt user communication and are subject to being garbled by the conversation of the TDD users ordinarily occurring at the same time.
These limitations might be readily overcome by redefining the communication protocol of TDD devices, for example, by using a higher speed protocol with a greater number of bits such as in the commonly used information protocol of the electronics industry, referred to as ASCII (American Standard Code for Information Interchange). The ASCII code provides eight bits of code words or 256 different code words and is considerably faster than the Baudot standard starting at 300 as opposed to 45 Baud. However, such a redefining is not practical because of the large installed base of TDDs in use in many parts of the world including the United States. A new protocol if implemented and if not compatible with this installed base would be of limited value if it could not communicate with normal Baudot terminals. The value of the TDD system is in the existence of many compatible terminals.